Internet Info 1993/Internet Info CD-ROM (Walnut Creek) (1993).iso/inet/ietf/mospf/mospf-minutes-91nov.txt

Text File | 1993-02-17 | 9.8 KB | 259 lines

CURRENT_MEETING_REPORT_


Reported by Scott Brim/Cornell University

Minutes of the Multicast Extensions to OSPF Working Group (MOSPF)


  1. Agenda

       o Roster, Intros, Notetaker
       o Reports on Related Activities
         -  X3S3.3?
         -  BGP?
         -  Router Requirements?
       o Review of Latest MOSPF Draft
         -  Scott's Comments
         -  Forwarding Algorithm
         -  Extent of Reverse Paths
         -  Inter-AS Interactions
         -  ``Host'' Behavior of MOSPF Routers
       o Token Ring Address Mapping
       o Multicast Scope Proposal
       o Implementation Status
       o Future Work
         -  MIB
         -  Standards Track
         -  Field Tests / Interoperability Tests


  2. Reports on Related Activities

     X3S3.3:  Recently started work on ``advanced services,'' including
     multicast.  Steve Deering addressed them on multicasting model and
     MOSPF. Dave Marlowe has draft extension to CLNS for join & leave
     group, proposal for NSAP assignment; other stuff.  Nobody knows
     what happened at the last meeting in Boston.
     BGP: Internet Draft issued on alternative approaches.  Only one
     person signed up to implement (Scott Brim) and he's not going to do
     it until after he finishes MOSPF. Not this year.
     Router Requirements:  Multicast will not be in the forwarding MIB
     because ???  it uses source address and nothing else in there does
     right now.  They're going to wait.  Someone is going to have to
     write a multicast routing MIB in addition to the different MC
     protocol MIBs.  John Moy contributed a section on multicasting
     router requirements which will have to be revised, and soon.

  3. Review of Latest MOSPF Draft

     3.1.  Discussion of Scott Brim's Previously Emailed Comments
     How do you tell what the previous hop of a packet was?  You can't

                                   1





without looking at the previous hop's link-level address.  The
issue is that on a border network you need to determine whether a
packet you receive was being multicast *through* your autonomous
system or just *getting* to your autonomous system?  (See figure in
draft.)  That's why we came up with datalink unicasting.  It looks
like this area of interactions between OSPF and RPF protocols isn't
finished.  Datalink unicasting is a start, but doesn't cover
everything.  We're going to have to study this one more.  Do we
have to encapsulate when crossing an AS boundary?  Right now the
BGP model is straight RPF, and RPF has no idea what an AS boundary
is.
Perhaps if there's a host sitting on the border LAN, then you only
accept unicasts *unless* the packet originates on that LAN.
Datalink unicasting is for transits, not for locally-originated
traffic.  What if someone is *sending* to a group that host belongs
to?
In BGP, only one AS announces the shared net.  Should we combine
the flags that say you shouldn't listen to multicasts with the one
that says to do datalink unicasts?
One definite conclusion is that you shouldn't base *forwarding* on
whether something came from another AS. In *building* the FIB
that's important, but should not be used after that.
Caching negative results is already in the document.
What if a vertex is not labelled?  Yes, document needs a statement
saying go to the next section.
Yes, there should be justifications for why we did *not* do things
in some way.

3.2.  Forwarding Algorithm

Moy:  Spell out preprocessing.  When called (directly from IP
forwarding), first check:

  o If 224.0.0.1 to 224.0.0.255, never forwarded, only sent to
    internal applications.
  o If IGMP message, send to IGMP process, don't forward.
  o Then follow rest of section.

Internally generated multicast packets must be handled differently
-- in John's design at least.  This is *not* true in Steve's
design, and we spent a significant amount of time comparing them.
Steve:  host specification (RFC 1112) says group membership is
associated with an interface.  Forwarding sends to a set of
outgoing interfaces.  As *part* of forwarding to an interface, in
the per interface code, if this host is a member of the destination
group *on that interface*, this host receives a copy, not by
interface loopback but in memory.  An application which joins on

                              2





multiple interfaces receives multiple copies.  Also, if this host
*sends* a packet, if this is a forwarder, the packet is looped back
in the interface handler for the interface the packet is being sent
on, and given to the forwarder which forwards it as necessary as if
it *came* from that interface.  A multicast packet, when it hits
the forwarder, is always associated with an interface.  The
forwarding function is thus relatively pure.
John says if you're only doing MOSPF, membership can be associated
with the router, not with a particular interface, so local delivery
is hung off the packet forwarder.  If originated locally, a packet
goes directly to the forwarding process, which knows which
interface you want to forward it out of, and decides whether to
deliver it locally.  If an interface goes down, with the Deering
scheme, then the application has to rejoin on another interface or
it doesn't receive any traffic.  Steve's model is necessary for a
multihomed host; John's is possible on an MOSPF router because of
its complete knowledge of the topology.  However, the programmer's
interface shouldn't change depending on whether MOSPF is running or
not, so maybe you should still do it with interfaces.
The time to join on more than one interface is, for example, when
you are doing an expanding ring search, and you want to get a hit
on any interface.  Also, Steve's model gives you the possibility of
making sure you only receive a packet for a particular group on
*one* *particular* interface.  John's model has the *router* being
a member, on *any* interface, so the router as a whole gets a copy
of a packet.  Steve was forced into his approach to make multihomed
hosts work.  If we allow both models, then yes, the environment
does change for applications -- applications can't receive multiple
copies with John's approach.  An artifact of Steve's approach is
that the packet goes out on the intended interface with the
intended TTL, and goes out on other interfaces (if it needs
forwarding immediately) with the TTL one less.  Steve's gut
reaction is that applications won't care if they don't get multiple
copies, but he doesn't know for sure.  John *can* emulate all of
Steve's behavior, delivering duplicate packets -- but would it be
better if he didn't.

3.3.  Extent of Reverse Paths

Within the area where the source is you still use forward costs.
Everywhere else you use all reverse costs.  If you don't use *all*
links in the *reverse* direction, you get pockets of non-delivery
of datagrams.  The problem occurs when you have asymmetric
reachability or costs on links within a receiving area.  Steve
thinks this is a problem due to the way John stores his information
and due to his decision that a multicast routing table entry is
simply a pointer to a unicast entry and a group address.  Steve
thinks the information for using forward costs is there, but not
used.  This discussion was not really concluded.

3.4.  Inter-AS Interactions


                              3





     Covered already in the section on ``Scott's comments''.

     3.5.  ``Host'' Behavior of MOSPF Routers

     Covered already in the section on ``Forwarding algorithm''.

  4. Token Ring Address Mapping

     A functional address for carrying IP multicasts on token ring has
     not yet been obtained.  Steve could write a one-page RFC on how to
     use it if he only had the address.  Coltun will follow up on it.

  5. Multicast Scope Proposal

     Steve's proposal reviewed.  (1) local wire, already allocated as
     224.0.0.1,255; (2) site-wide -- start allocating from the bottom up
     at 224.0.1.0; (3) global, allocated from 249.255.255.255 downward.
     Thus we can decide about the middle later.  This would require the
     number czar to ask multicast group requestors just what they are
     going to be used for and make an intelligent allocation based on
     what they say -- this might not be acceptable.

  6. Implementation Status

     Not covered.

  7. Future Work

     7.1.  MIB

     No volunteers came forward.

     7.2.  Standards Track

     Not covered.

     7.3.  Field Tests / Interoperability Tests

     Not covered, except to say that we should try to line up some test
     beds.



Attendees

Nagaraj Arunkumar        [e-mail]
William Babson           [e-mail]
Atul Bansal              [e-mail]
James Beers              [e-mail]
Scott Brim               [e-mail]

                                   4





Yee-Hsiang Chang         [e-mail]
Dean Cheng               [e-mail]
Rob Coltun               [e-mail]
Steve Deering            [e-mail]
Kurt Dobbins             [e-mail]
Dino Farinacci           [e-mail]
Karen Frisa              [e-mail]
Jim Ghadbane             [e-mail]
Christine Hemrick        [e-mail]
Ronald Jacoby            [e-mail]
Jean-Michael Jouanigot   [e-mail]
Stev Knowles             [e-mail]
Mark Lewis               [e-mail]
April Merrill            [e-mail]
Greg Minshall            [e-mail]
Dave Monachello          [e-mail]
Dean Morris              [e-mail]
John Moy                 [e-mail]
Andy Nicholson           [e-mail]
Stephen Shew             [e-mail]
Ravi Srinivasan          [e-mail]
Michael St.  Johns       [e-mail]
William Townsend         [e-mail]
Scott Wasson             [e-mail]
L. Michele Wright        uncng![e-mail]



                                   5